1. Field of the Invention
This invention generally relates to communications between applications or processes in a data processing system or network and more specifically to communications adapted for use in a database management system that alert one or more applications that another application has caused a change the database.
2. Description of Related Art
Database management systems have become important tools recent years because they enable a quick and inexpensive retrieval of specific data from a large amount information in response to a number of criteria and facilitate the maintenance of that information. Database management systems have two basic components commonly called a "database" and a "database manager" that typically reside in a data processing system or a network of data processing systems. Databases include census information, airline schedules, stock prices and library catalogs to name a few examples and typically are stored in disk storage facilities. A database manager includes various software that enables the maintenance of and access more databases. It is the database manager that enables the addition, deletion and modification of data in the database and the transfer of data from the data base.
A data processing network has the capability of transferring information between various identified nodes on a communications path. Each node may comprise any of a variety of data processing equipment and components. In a typical network installation, a database management system may locate a database in a storage means at one node and the database manager, or portions thereof, at the database node or at any other node that can communicate with the database.
Communications over the network between nodes may take the form of messages or packets that contain an actual message and a number of overhead or communications related messages for controlling the communications. In many networks, the time required to transfer an actual message is essentially independent of the length of the actual message because the time required to process overhead or communications related messages and the communications programs they invoke are very long in comparison to those required to process the actual message.
Although this invention can be implemented on a number of different database management systems, the invention and its background are most readily understood by describing them in terms of a relational database management system provided by the assignee of this invention, Interbase Software Corporation. A relational database as found in such a system contains data that users perceive as a collection of relations. Each such relation comprises a number of records and each record contains one or more fields. Each field has a name and contains data. In other database management systems phrases such as "table-row-column", "table-tuple-domain" or "file-record-field" are synonymous for the "relation-record-field" syntax used in the Interbase Software Corporation relational database management system.
As an example, a simple relational database called "commodities" might have a series of records each containing several fields. A field called "Name" in each record would identify a particular commodity, such as pork bellies, soybeans or sugar. Another field called "Price" in each record would contain the price of the named commodity. Still another field called "Trades" would record the number of shares traded on a given day. Another relational database called "monitor" might have a series of records each containing "Sensor Name" and "Sensor Value" fields for monitoring the outputs from a number of different sensors in a chemical or similar process.
Database management systems usually allow the construction of various applications or user programs that modify the database by adding or deleting records or by changing fields in the records or by adding fields to or deleting fields from the records, all on a selected basis. Other applications produce reports or evoke other responses based upon selected data in the database. For example, an application might generate a report listing the name and price of every record or a subset of selected records from the previously defined commodities or monitor databases.
It oftentimes is desirable to produce a report or evoke some action whenever a value in a particular field changes or values in a combination of fields change. A report, for example, might take the form of a message sent to a particular broker using the commodities database whenever the price changes for a particular commodity or subset of commodities. Evoking an action might take the form of initiating some particular control action whenever the output from a sensor, as recorded in that sensor's Sensor Value field, exceeds some threshold value.
In each of the foregoing and other examples it is necessary to establish communications with one application that depends upon the occurrence of an event in response to changes produced by another application. Several approaches exist for reporting the occurrence of such events in prior art data processing systems including those that contain database management systems.
In dedicated data processing systems, an interruption subsystem handles such communications when an event occurs. Each possible event has an interruption priority and transfers an interruption signal to the interruption subsystem. When the interruption subsystem responds to the interruption signal, it stops further processing of any application and initiates an interruption process for responding to the interruption signal with the highest priority. This interruption process may either poll all possible interrupting sources or receive a vector address that identifies an application interruption process to identify the interruption source and an appropriate response.
In many cases, there is no synchronization between the occurrence of an event and the operation of the interruption process, particularly when an event with a low priority must compete with higher priority events for use of resources in the data processing system. In such situations significant delays between the event and the response can occur or, in some cases, the system may fail to produce any response to the event. As a result, the viability of this approach tends to be limited to single data processing systems that use reasonably short interruption processes to respond to a reasonably small number of events that occur asynchronously to an application. Interruptions produced by keyboards, clocks, external sensors and related devices are examples of interruptions that typically require relatively short interruption processes that do not necessarily monopolize the data processing system for significant time periods.
As disk memories became more popular with the attendant development of disk operating systems, communications by means of interruptions became more complex to implement. One manufacturer has proposed to use event counters operating under the disk operating system to provide such communications. In accordance with this approach, the operating system manipulates a first array of event counters and a second array that contains a threshold value for each of the counters. When an application is to wait for the occurrence of one or more events, it specifies the corresponding events by identifying addresses in each of the arrays and then entering a wait state. When an event occurs, the operating system restarts the application. The application then determines whether an event of interest has occurred and performs certain housekeeping chores to maintain a correct correlation between the event counter and the application.
Although this approach provides a means for establishing communications between two applications, the applications must run on the same node in a network. It is not possible to implement this approach on a network with multiple systems of the same or different manufacturers because it is impossible, from a practical standpoint, to allow different systems to access specific locations in one system's memory. Further, the definition of an event counter for other than certain predetermined conditions does not always produce repeatable and predictable results. Thus, this approach is not practicable to apply to database systems where the change in a field or number of fields is of interest to one or more applications that operate at a single site or multiple nodes in a homogeneous or heterogenous network.
Prior database systems use polling techniques to monitor changes in the database. Such polling techniques repetitively access the database to determine if a change has occurred in any selected field. A polling technique might require (1) an identification of the database, a record or records and a field or fields of interest, (2) the retrieval of the field or fields, (3) a determination if the field has changed and (4) the notification of any application interested in that change. As well known, the repetition rate for such polling techniques must be at least two times greater than the maximum frequency at which each field changes; otherwise changes can occur without detection. As the repetition rates increase to provide adequate sampling, these polling programs can require a significant percentage of available resources even in a dedicated system. This use of resources can degrade overall system performance either by interrupting other applications or by being interrupted with the potential for missing some change.
These disadvantages become evident particularly when the database management system operates in a network environment and the polling repetition rate increases. Even when polling procedures require only a minimal level of resource utilization, problems can still exist in a heterogeneous network characterized by the presence of data processing equipment from different manufacturers at different nodes. Polling in such heterogenous networks, even if possible, can increase the demands on various network resources to unacceptable levels. However, notwithstanding these various disadvantages, polling has continued to be the dominant method of monitoring a database for a change in the value of any field.